Rompiendo mitos: Por qué pasar de VPN a ZTNA no tiene por qué ser una tarea tediosa

En los últimos años, muchas organizaciones ya han introducido una solución Zero Trust Network Access (acceso a la red basado en confianza cero o ZTNA) y están viendo sus beneficios. Pero muchas otras se han visto desalentadas por el trabajo necesario para la transición a un modelo de acceso basado en confianza cero y el trabajo de integración técnica asociado. En este artículo de blog explicaré los aspectos que hay que tener en cuenta y compartiré algunas ideas sobre cómo las organizaciones pueden empezar ahora su transición a ZTNA, realizando la transición completa con el tiempo, rompiendo algunos de los mitos más comunes que he oído. 

Muchos de los problemas habituales de las redes privadas virtuales (VPN) son bien conocidos, ya se trate de problemas de seguridad relacionados con el cifrado y la autenticación, de que la premisa original de una VPN ya no es adecuada para la forma híbrida en que trabajamos hoy en día y, por supuesto, de las implicaciones para la seguridad de permitir conexiones entrantes a una ubicación. 

ZTNA pretende resolver cada uno de estos problemas, utilizando una capa en la nube para intermediar en las conexiones entre usuarios y aplicaciones, aunque la conectividad fiable y rápida a las aplicaciones sigue siendo un problema para las organizaciones. Un informe reciente de Cisco afirma que el 51% de las organizaciones encuestadas han tenido problemas para conectar a los trabajadores con los recursos de la empresa en los últimos 18 meses.

Conectar a las personas con las aplicaciones no debería ser una tarea difícil y los cinco mitos siguientes son las razones más comunes que escucho para explicar por qué las organizaciones aún no han adoptado una estrategia ZTNA.

Mito 1: No tengo la información necesaria para crear una política basada en confianza cero 

Este mito se puede dividir en dos componentes: o bien no se dispone de información sobre el entorno de las aplicaciones, o bien no se dispone de información sobre los grupos de usuarios y los permisos de acceso.

Ambos pueden resolverse mediante una migración bien pensada y una planificación previa para identificar los casos de uso más importantes y los datos más valiosos. A ello puede contribuir la colaboración con otras iniciativas, incluidos los proyectos de migración a la nube. El problema del descubrimiento de aplicaciones también puede solucionarse con herramientas de descubrimiento integradas en las soluciones ZTNA y Security Service Edge (servicio de seguridad en el borde o SSE). 

Por último, la organización siempre llevará a cabo una migración escalonada de usuarios al implementar ZTNA, lo que le permitirá crear las políticas de acceso adecuadas con el tiempo. Comience con las aplicaciones y usuarios de alto riesgo para obtener resultados rápidos, cree una política basada en confianza cero para el acceso a las aplicaciones de alto riesgo y migre los servicios con el tiempo, creando una política integral de confianza cero para respaldar el acceso basado en ZTNA.  

Mito 2: Implementar la confianza cero y ZTNA parece una gran tarea

Se puede entender por qué existe este mito, pero es importante recordar que la confianza cero y ZTNA no son lo mismo—hay una forma sencilla de desvincular ambas. La confianza cero es una forma de pensar y puede traducirse en una estrategia de seguridad que permite eliminar sistemáticamente la confianza implícita. ZTNA es el mecanismo y la tecnología para implementar la confianza cero en el acceso remoto a las aplicaciones. Dicho esto, ZTNA es un gran primer proyecto para comenzar su viaje hacia la confianza cero, uno que muchas empresas emprenden y que no requiere una gran inversión de recursos para introducirlo.

Mito 3: ZTNA añadirá un cliente más a mi endpoint

Es cierto que muchas soluciones ZTNA tienen un cliente para el punto final para gestionar las conexiones, así como para ejecutar comprobaciones de postura y proporcionar integración con proveedores de autenticación. ZTNA también se puede proporcionar a través de conexiones basadas en navegador sin cliente, pero, aunque esto resuelve el problema de "no estamos poniendo otro agente en el endpoint", no permite muchas de las ventajas de desplegar un cliente. El enfoque de Netskope es único en el mercado, ya que proporciona un único agente para todos los aspectos de Secure Access Service Edge (servicio de acceso seguro en el borde o SASE). Un agente que no solo proporciona acceso remoto, sino que también dirige el tráfico web y de aplicaciones en la nube, inspecciona el contenido, facilita el DLP para punto final y proporciona formación y comentarios al usuario final. 

Esta es una de las razones por las que las organizaciones deberían considerar siempre sus planes a largo plazo para SASE. Si ZTNA es el primer paso en su viaje SASE, deben asegurarse de que la plataforma que elijan proporcione todas las capacidades que necesitarán para una oferta SASE unificada en el futuro.

Mito 4: ZTNA es sólo un sustituto de las VPN

Aunque ZTNA sustituye a muchos de los casos de uso soportados por una VPN hoy en día, para muchas organizaciones su proyecto inicial de ZTNA está impulsado por la necesidad de proporcionar acceso de contratistas y terceros a aplicaciones internas. 

Estas iniciativas de acceso son a menudo completamente independientes de proporcionar acceso remoto a los empleados, y ofrecen los primeros casos de uso perfectos para ZTNA, donde no se puede aplicar el mismo nivel de confianza implícita al dispositivo o usuario que se conecta a la aplicación o red. 

Otro caso de uso común para ZTNA es dar soporte a fusiones y adquisiciones, permitiendo un aprovisionamiento muy rápido y una escalabilidad que no ofrecen las VPN tradicionales, especialmente en un mundo más híbrido en el que la mayoría de los concentradores VPN están funcionando casi a su máxima capacidad. 

Mito 5: Las VPN y ZTNA no pueden funcionar juntas

Para mi último mito me gustaría abordar un punto de discusión común. Muchas organizaciones necesitan mantener una capacidad VPN limitada para las aplicaciones tradicionales y, por lo tanto, creen que también podrían mantener la VPN para todos los usuarios.

Esta forma de pensar no tiene en cuenta una de las principales razones para desplegar ZTNA: proporcionar un control granular de las políticas, incluidas las políticas de acceso a las aplicaciones que tienen en cuenta el contenido. Las soluciones ZTNA reducen el riesgo, no sólo de acceso directo no autorizado o acciones de riesgo, sino también el movimiento lateral. 

Muchas organizaciones utilizan VPN y ZTNA en paralelo, realizando cambios en las políticas de acceso y enrutamiento de VPN una vez que se ha desplegado ZTNA, para reducir el riesgo asociado con el compromiso de VPN. Con el tiempo, a medida que las organizaciones completan sus proyectos de transformación digital, eliminando gradualmente las aplicaciones tradicionales y las soluciones VoiP, pueden retirar completamente su VPN. 

 Hacer funcionar las VPN y ZTNA al mismo tiempo también ayuda a poner de relieve una solución a algunos de los problemas más comunes con las VPN hoy en día relacionados con el rendimiento, los problemas de red/conectividad y el costo de retornar el tráfico a través de un centro de datos. Migrar el tráfico de una VPN a ZTNA y a una plataforma SASE o SSE más amplia resuelve estos dos problemas y, en última instancia, reduce los costos generales. 

Para más información sobre varios de los puntos tratados en este blog, lea nuestra Guía práctica de la ZTNA.